A process object is an object in a computer system that describes the structure and behavior of a business process. As such, the process object may include data, logic, and structures. The process object may have data and routines to manipulate the data, as in object-oriented objects, and structures, e.g., database tables, to describe the relationships (or associations) with other process objects, as in relational database objects. In a system, these process objects are generally the core structuring components to encapsulate the functionalities that applications need to implement business processes. Each process object advantageously provides a discrete representation of the structure and behavior of a business process. An application to implement a business process may then advantageously access the appropriate process objects and their data, without having to know the details of the underlying implementation.
This process object encapsulates the business process' functionality within the object itself (and, in some cases, in other entities referenced by the object), defines relationships between different components and process objects, and provides the basic building block for applications. This process object encompasses traditional objects as well as object-oriented business objects. This means that the process object encapsulates and/or defines functionality at a high level by referring to the business modules that provided the functionality. The business modules are the basic building blocks for applications. The process object also may include structural information about the object's relationships.
Process objects are generally the core structuring components in a system. In situations where a user needs to see the past content history, it would be useful if the process objects were designed to maintain certain time information to assist in viewing different data during the lifetime of the matter being modeled.
Available tools, e.g., those effecting change documents, are not effective to assist in viewing past history because they are set to show, e.g., only the singular change made, not to show the complete object. Events, for example, may include creation, modification, changes, and/or deletions to content and/or structure of an object. The available change documents only enable logging at a field level of all changes to an object. In available change documents, one cannot determine the full content of the object at a specific time point in the past. Further, the object can still be subject to structural changes that are time dependent which is not taken into account by present change documents. Thus, at various times in the past the object may have had different structures and/or different content. And, with existing methods and functions, a determination and display of the content of an object can require a large amount of time-consuming research and manual effort.
Accordingly, there is a need in the art for an effective way to maintain and access past history of an process object to provide for viewing past events and/or modifications at specific time points.